DevTool Custom Component Scenario
The MAX Development Tool is able to generate Visual Studio Projects and Solutions from scratch that automatically link into SOLIS as DLLs. As part of this example scenario, a DevTool Project "CustomComponent" has been started for you. Once you walk through the example project, you should have the knowledge you need to start building any custom logic you desire.
Opening the SOLIS Scenario
- Open the
SOLISExample_DevToolCustomComponent.scfile and go to the Development Tool page in SOLIS. In the Scenario DLL List there is aCustomComponent.DLL. - Click
at the top of the page.
- Modify the DevTool UI settings as shown below with the Base Directory at
C:\ProgramData\AGI\STK 12\SOLIS\ExampleScenarios\SOLISExample_DevToolCustomComponent\CustomComponent.
- Once your settings are updated, go to the File menu and select "Save as Batch File"
to create C:\ProgramData\AGI\STK 12\SOLIS\ExampleScenarios\SOLISExample\_DevToolCustomComponent\RunDevTool.bat.
Opening the VS CustomComponent Solution
The MAX Development Tool interprets XML files from the xml directory of your project using an XML Schema. The Schema will guide you in writing valid syntax. Let's explore the CustomComponent Project by opening the C:\ProgramData\AGI\STK 12\SOLIS\ExampleScenarios\SOLISExample_DevToolCustomComponent\CustomComponent\CustomComponent.sln file in Visual Studio 2017.
Understanding the CustomComponent XML File
Look at the Custom Component solution below. In the CustomComponentXML.xml, some lines (after line 25) have already been created and run through the DevTool. This file is what the DevTool interprets to build the C++ code. From there, you add logic to your C++ code.
*.auto.hpp, *.auto.cpp, *.hpp, and *.cpp files. The *.auto.* files are NOT to be edited by the user. User code goes in the nonauto files. The DevTool will not clobber user-written code in the nonauto files.
The file is broken down as such:
| Line Sections | Details |
|---|---|
| 18-24 | This section defines a File Header Text that will be placed at the top of your files upon generation of those files. Once the file has been generated, the Header Text will not change. |
| 26-36 | These lines define a Namespace where common Constants, Structures, Enumerations, etc. can be stored and referenced throughout the project. In this example, there is a defined enumeration and structure. |
| 37-42 | These lines define an interface that is used to pass/grab data between Components in the system. In this case, the interface contains four properties. |
| 44-56 | These lines define the Component that produces the ODY_Disturbance (defined in the ADCS XML) and the MyInterface interfaces. It also connects to/gets data from a FSW_Ephemeris and FSW_AttDetermination interface. There are two parameters (V_ConstantDisturbance_Nm and E_MyEnum) in this Component, which you can set via the Configuration Manager or in configuration files. Lastly, the Component is producing telemetry of a torque VECTOR. |
Writing the Logic
Even in the CustomDisturbance.cpp file, the DevTool manages a large portion of the required syntax. It is simply up to you to write the logic within the function stubs.
Start with the functions at the end of the file, shown below. There are four functions visible with a "From interface:" comment above them. These items implement what this component returns when another component requests, for example, GetTorque_BDY_Nm(). The only portion that was manually written was the return m_Tlm.MyTorque_Nm; statement.
Now looking above at the Iterate() function. This is where the bulk of the custom logic was written. The example is intentionally generic but does prove the necessary points to get started. Here, we have grabbed data from another component (FSW_Ephemeris) using the m_Connection structure. That data is then used to create a sinusoidal torque which is pushed into the telemetry, m_Tlm, variable.
Useful Structures to Know
| Structure | Description |
|---|---|
m_Connection
|
The connections from other interfaces |
m_Parm
|
The parameters that you've specified for this component |
m_Tlm
|
The telemetry that you've specified for this component |
m_Data
|
(Optional) See "GeneratePropertyDataStructure" in the MAX DevTool XML Guide |
At this point, there is some logic that can produce a custom torque. Now it's time to configure this into the system.
Configuring to Use Custom Disturbance Component
Before you go any further, open the SOLISExample_DevToolCustomComponent.sc file and go to the SOLIS Development Tool page. Ensure that the Scenario DLL List contains a CustomComponent.DLL. To verify this is working, rebuild your CustomComponent.sln solution. Then click 
on the Development Tool page.
CustomComponent.sln project, you should see the timestamp on this DLL update.In your SOLIS scenario, go to the Configuration Manager page. This is where you will configure the system to build, use, and connect the new "CustomDisturbance" Component. This scenario has the following steps completed, but here are the steps to walk through them:
Step 1: Create a custom Configuration Set
Step 2: Add an instance of the CustomDisturbance to the CustomConfigSet
Step 3: Configure the CustomDisturbance to have it's connections and parameters
Step 4: Create a custom Version of ODY_EquationsOfMotion
Step 5: Add a Disturbance connection to the ODY_EquationsOfMotion from the new CustomDisturbance
Step 6: Set the CustomConfigSet as the Configuration Set to run
Running the new setup
With the "CustomConfigSet" selected, you should now notice a "Custom" Group on the Telemetry page. This is coming from your new CustomDisturbance! Go ahead and Run the Simulation.
Below you can see the torques and momentum getting into the system. If you take a quick look at the logic in the Iterate() section, you are creating torque until the Body Rates get above 5 deg/s. You can see the logic (though unusual) is working perfectly. That should be enough to get you started playing around. The possibilities are endless. Enjoy!
The Custom Development Process
